Update CI runner to ubuntu-22.04#60
Conversation
The ubuntu-20.04 runner image is no longer available, causing jobs to hang waiting for a runner. See: https://github.blog/changelog/2025-01-15-github-actions-ubuntu-20-runner-image-brownout-dates-and-other-breaking-changes/
|
This PR addresses the CI runner image issue per @alexander-schranz' comment on #59. With the runner updated to The pipeline runs now surface pre-existing failures that are not caused by this PR (verified on
These can be tackled in follow-up PRs once the runner is unblocked. |
- Update CI runner from ubuntu-20.04 to ubuntu-22.04 - Replace 'doctrine:database:create' (unsupported on DBAL 3 SQLite platform) with a touch on the sqlite file before schema:create - Pin symfony/var-exporter to ^6.4 || ^7.0 so doctrine/orm 3.6 can find ProxyHelper::generateLazyGhost, which was removed in Symfony 8 - Widen TaskExecutionRepository::create to accept DateTimeInterface and normalize to DateTimeImmutable, so DateTime returned by CronExpression::getNextRunDate() in upstream TaskScheduler is accepted - Add ArrayTaskExecutionRepository subclass that performs the same normalization for array storage and initializes the result field so getResult() returns null instead of false (unserialize(null) === false) - Update tests to call findAllPaginated() instead of removed findAll()
| <services> | ||
| <service id="task.storage.task" class="Task\Storage\ArrayStorage\ArrayTaskRepository" public="true"/> | ||
| <service id="task.storage.task_execution" class="Task\Storage\ArrayStorage\ArrayTaskExecutionRepository" public="true"/> | ||
| <service id="task.storage.task_execution" class="Task\TaskBundle\Storage\ArrayStorage\ArrayTaskExecutionRepository" public="true"/> |
There was a problem hiding this comment.
this looks unexpected whats wrong with: https://github.com/php-task/php-task/blob/master/src/Task/Storage/ArrayStorage/ArrayTaskExecutionRepository.php ?
There was a problem hiding this comment.
Reverted in b1a79a9 — the subclass was only there to mirror the workaround above, so it's gone too. Fix needs to happen upstream in TaskScheduler.
| * {@inheritdoc} | ||
| */ | ||
| public function create(TaskInterface $task, \DateTimeImmutable $scheduleTime) | ||
| public function create(TaskInterface $task, \DateTimeInterface $scheduleTime) |
There was a problem hiding this comment.
this does not reflect the interface: https://github.com/php-task/php-task/blob/2c9685e1188a0054a28f2036a449fdc293563c63/src/Task/Storage/TaskExecutionRepositoryInterface.php#L30
So I would not do that I think it more requires handling converting DateTime to DateTimeImmutable on caller side.
This is else a BC Break.
There was a problem hiding this comment.
Good catch — you're right, widening the parameter is a BC break. Reverted in b1a79a9. The conversion has to happen in the upstream TaskScheduler (which is where the DateTime from CronExpression::getNextRunDate() enters the call). I'll open a follow-up PR on php-task/php-task.
|
Follow-up upstream fix opened: php-task/php-task#54 — fixes the caller-side |
Revert the changes that altered TaskExecutionRepository::create() to accept DateTimeInterface and that subclassed the upstream ArrayTaskExecutionRepository. The interface requires DateTimeImmutable and widening it breaks BC for consumers. The conversion belongs on the caller side (upstream TaskScheduler in php-task/php-task), not on every TaskExecutionRepository implementation.
b1a79a9 to
6a33385
Compare
What's in this PR?
Replace
ubuntu-20.04withubuntu-22.04for the test workflow runner.Why?
The
ubuntu-20.04GitHub Actions runner image is no longer available, so CI jobs hang waiting for a runner until they hit the 24h timeout. See GitHub's changelog and sulu/sulu#7615 for reference.